Userlib: Fix endianness in request id calculation#319
Userlib: Fix endianness in request id calculation#319chenyan-dfinity merged 4 commits intomasterfrom
Conversation
this is the equivalent of what #303 did to `dfx`: When CBOR-encoding a canisterid for submission in a request, we need to make sure it is little endian. We do the change in ``` class CanisterIdEncoder implements CborEncoder<CanisterId> { … ``` where it belongs: As close to the HTTP interface we can. This means that once we migrate to https://github.com/dfinity-lab/dfinity/pull/2286 we will adjust this code to switch to CBOR blob, and the work-around can be dropped here. Note in the code about that. Also cleans up `fromText` to be more robust: It will _only_ accept `ic:` textual representation, and _always_ strip the checksum. With this, I can * build and install Linkedup * copy the `ic:` url printed by `dfx` upon installation * use that in the url (e.g. `http://127.0.0.1:8000/?canisterId=ic:72028DEDFB546FA89A`) * see it load the assets
nomeata
force-pushed
the
joachim/userlib-request-id
branch
2 times, most recently
from
42a1ce3 to
3b4ca63
Compare
nomeata
force-pushed
the
joachim/userlib-request-id
branch
from
3b4ca63 to
f5d0450
Compare
|
(doesn’t cut it yet) |
|
Yes, this fixes it (Remember to Shift-Reload the browser…) |
|
So #317 fixed the retrieving asset problem, and this PR fixes the whole thing? |
That's what I understood from @nomeata. https://dfinity.slack.com/archives/CGA566TPV/p1579105147298200?thread_ts=1579080257.280600&cid=CGA566TPV |
|
hmm...i still get the |
Did you shift - Reload in the browser? What is your testcase?
|
|
Yes, manual testing the default |
ggreif
changed the title
chenyan-dfinity
left a comment
chenyan-dfinity
left a comment
There was a problem hiding this comment.
ok, this indeed works on the default app. I wasn't rebuilding a new version of dfx, so nix is fetching an old version js lib.
I still cannot get my matrix multiply example to work. Let's merge to master first.
I wonder how many developer days we have lost due to ~/.dfinity/cache being stale, or not using the right version of dfx, or the browser cache caching the user lib. |
@hansl This is indeed very painful. Any way we can design this better? At least, if I'm in |
|
Agreed. Shouldn't be a big change. |
None. End-developers (users?) will not see cache being stale (because we don't release twice with the same version). This is only a problem when developing dfx itself, and could be fixed with a simple change. Version numbers save lives! |
|
I’d say content-addressed caches save lifes… What’s the “simple change” you envision? |
|
If your versions don't change when your content changes, I feel bad for you son ;) Simple change -> If dirty version (ie. built from sources), invalidate cache. |
|
Hmm, if the performance hit of extracing the data upon every invocation to |
|
Extracting cache is ~500 msec, but isn't necessary for all commands (e.g. dfx canister call doesn't require the cache). |
Then feel bad for everyone trying to use dfx from source. Because if I build |
|
Yup, I feel bad for us; that's why I'm doing that simple change. My original point though was that no users would be affected. |
|
Until users start building from source :-) |
4 participants
No description provided.